Domain Controller Configuration

The domain controller is the central government for a managed domain. A domain controller configuration requires two steps:

• A host needs to be configured to act as the Domain Controller for the whole domain

• The host must expose an addressable management interface binding for the managed hosts to communicate with it

Configuring a host to act as the Domain Controller is done through the domain-controller declaration in host.xml. If it includes the <local/> element, then this host will become the domain controller:

<domain-controller>
   <local/>
</domain-controller>

_{(See domain/configuration/host.xml)}

A host acting as the Domain Controller must expose a native (i.e. non-HTTP) management interface on an address accessible to the other hosts in the domain. Also exposing an HTTP management interface is not required, but is recommended as it allows the Administration Console to work:

<management-interfaces>
   <native-interface interface="management" port="9999" />
   <http-interface interface="management" port="9990" />
</management-interfaces>

The interface attributes above refer to a named interface declaration later in the host.xml file. This interface declaration will be used to resolve a corresponding network interface. 

<interfaces>
   <interface name="management">
       <inet-address value="192.168.0.12"/>
   </interface>
</interfaces>

_{(See domain/configuration/host.xml)}

Please consult the chapter "Interface Configuration" for a more detailed explanation on how to configure network interfaces.

Host Controller Configuration

Once the domain controller is configured correctly you can proceed with any host that should join the domain. The host controller configuration requires three steps:

• The logical host name (within the domain) needs to be distinct

• The host controller needs to be addressable by the domain controller (interface binding)

• The host controller needs to know the domain controller IP address

Provide a distinct, logical name for the host. In the following example we simply name it "staging":

<host xmlns="urn:jboss:domain:1.0"
     name="staging">
[...]
</host>

_{(See domain/configuration/host.xml)}

Tell the host to expose a native (i.e. non-HTTP) management interface on an address accessible to the host that is acting as the Domain Controller. Exposing an HTTP management interface is not required, and is only necessary if the user has developed some custom HTTP-based management clients and wishes to use them to administer the host:

<management-interfaces>
   <native-interface interface="management" port="9999" />
</management-interfaces>

Assign an addressable IP address to the host controller itself. The address must be reachable by the Domain Controller:

<interfaces>
   <interface name="management">
       <inet-address value="192.168.0.101"/>
   </interface>
</interfaces>

_{(See domain/configuration/host.xml)}

Tell it how to find the domain controller so it can register itself with the domain:

<domain-controller>
   <remote host="192.168.0.12" port="9999"/>
</domain-controller>

_{(See domain/configuration/host.xml)}

Server groups

The domain controller defines one or more server groups and associates each of these with a profile and a socket binding group, and also :

<server-groups>
    <server-group name="main-server-group" profile="default">
        <jvm name="default">
           <heap size="64m" max-size="512m"/>
           <permgen size="128m" max-size="128m"/>
        </jvm>
        <socket-binding-group ref="standard-sockets"/>
    </server-group>
    <server-group name="other-server-group" profile="bigger">
        <jvm name="default">
            <heap size="64m" max-size="512m"/>
        </jvm>
        <socket-binding-group ref="bigger-sockets"/>
    </server-group>
</server-groups>

_{(See domain/configuration/domain.xml)}

The domain controller also defines the socket binding groups and the profiles. The socket binding groups define the default socket bindings that are used:

<socket-binding-groups>
    <socket-binding-group name="standard-sockets" default-interface="public">
        <socket-binding name="http" port="8080"/>
        [...]
    </socket-binding-group>
    <socket-binding-group name="bigger-sockets" include="standard-sockets" default-interface="public">
        <socket-binding name="unique-to-bigger" port="8123"/>
    </socket-binding-group>
</socket-binding-groups>

_{(See domain/configuration/domain.xml)}
In this example the bigger-sockets group includes all the socket bindings defined in the standard-sockets groups and then defines an extra socket binding of its own.

A profile is a collection of subsystems, and these subsystems are what implement the functionality people expect of an application server.

<profiles>
    <profile name="default">
        <subsystem xmlns="urn:jboss:domain:web:1.0">
            <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/>
            [...]
        </subsystem>
        <\!-\- The rest of the subsystems here \-->
        [...]
    </profile>
    <profile name="bigger">
        <subsystem xmlns="urn:jboss:domain:web:1.0">
            <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/>
            [...]
        </subsystem>
        <\!-\- The same subsystems as defined by 'default' here \-->
        [...]
        <subsystem xmlns="urn:jboss:domain:fictional-example:1.0">
            <socket-to-use name="unique-to-bigger"/>
        </subsystem>
    </profile>
</profiles>

_{(See domain/configuration/domain.xml)}
Here we have two profiles. The bigger profile contains all the same subsystems as the default profile (athough the parameters for the various subsystems could be different in each profile), and adds the fictional-example subsystem which references the unique-to-bigger socket binding.

Servers

The host controller defines one or more servers:

<servers>
    <server name="server-one" group="main-server-group">
        <\!-\- server-one inherits the default socket-group declared in the server-group \-->
        <jvm name="default"/>
    </server>

    <server name="server-two" group="main-server-group" auto-start="true">
        <socket-binding-group ref="standard-sockets" port-offset="150"/>
        <jvm name="default">
            <heap size="64m" max-size="256m"/>
        </jvm>
    </server>

    <server name="server-three" group="other-server-group" auto-start="false">
        <socket-binding-group ref="bigger-sockets" port-offset="250"/>
    </server>
</servers>

_{(See domain/configuration/host.xml)}

server-one and server-two both are associated with main-server-group so that means they both run the subsystems defined by the default profile, and have the socket bindings defined by the standard-sockets socket binding group. Since all the servers defined by a host will be run on the same physical host we would get port conflicts unless we used <socket-binding-group ref="standard-sockets" port-offset="150"/> for server-two. This means that server-two will use the socket bindings defined by standard-sockets but it will add 150 to each port number defined, so the value used for http will be 8230 for server-two.

server-three will not be started due to its auto-start="false". The default value if no auto-start is given is true so both server-one and server-two will be started when the host controller is started. server-three belongs to other-server-group, so if its auto-start were changed to true it would start up using the subsystems from the bigger profile, and it would use the bigger-sockets socket binding group.

<jvms>
    <jvm name="default">
        <heap size="64m" max-size="128m"/>
    </jvm>
</jvms>